Many electronic devices have at their core Application-Specific Integrated Circuits (ASICs), e.g. Integrated Circuits (IC) that are customized for a particular use. Verifying the correct operation within time-to-market constraints can be a challenge for ASIC design teams. For example, 35 to 45 percent of the total ASIC development effort may be spent on verification, and this fraction may continue to grow due to the constant increase of chip complexity. Moreover, debugging may consume about 60 percent of the total verification effort and may be the fastest growing component. For example, a large fraction of silicon IC re-spins may be at least partially due to functional errors and bugs inadvertently introduced at the register-transfer level (RTL) stage of the design process. Thus, comprehensive functional verification is the key to reduce development costs and to deliver a product on time. Embedded systems are becoming even more complex. Errors in the specification, the design and the implementation may be substantially unavoidable. Efficient verification tools for verifying designs are therefore important, and even more so for ASIC designs, where errors cannot be easily fixed. In addition, a late introduction of the product can invoke an important loss of revenues.
Thus, application specific integrated circuit (ASIC) verification and debugging has become a challenging and time consuming task in ASIC design, particularly because state of the art ASIC designs can be quite large and complex. Circuit designers may use software simulation, e.g. Mentor Graphics Model-Sim, to verify and debug circuits. This is extensively used because of its ease of use. For example, designers are able to view the behavior of any internal signal in the circuit and they can detect design errors, fix them and re-simulate. However, the inefficiency of software simulation and timing constraints can prohibit the debugging of complete systems through software simulation. Moreover, the complexity of integrated circuits continues to increase, consistent with Moore's Law. For a complex chip design, e.g. a computer central processing unit, software simulations may run a billion times slower than the intended silicon implementation.
Programmable logic devices (PLDs) can be used as building blocks in creating electronic circuit designs. A programmable logic device is a hardware component whose functionality can be configured. For example, Field Programmable Gate Arrays (FPGAs) are off-the-shelf integrated circuit PLDs that can be configured to implement any particular digital circuit design. In order to address challenges in ASIC verification and debugging, programmable logic devices such as FPGAs can be used to facilitate debugging. Of course, also designs that are being implemented on FPGAs from the beginning must be debugged. Implementing a logic design on a FPGA, e.g. implementing an abstract description of functionality defining a predetermined function when executing on the FPGA, may typically comprise the steps of synthesis, technology mapping, placement and routing. As for ASICs, the FPGA implementation can be performed entirely at design time, before the component is used. However, due to the inherent reconfigurability of static RAM-based FPGAs (SRAM-FPGAs), this implementation can also be performed on the fly, e.g. by run-time hardware generation. Unfortunately, state of the art methods for hardware generation can be computationally expensive, such that run-time hardware generation may not be feasible for most applications given realistic time constraints. Nevertheless, an FPGA emulation can bridge the gap between hardware prototyping and software simulation by providing an environment which is much closer to the device being simulated.
The simulation of complete circuit systems in an FPGA, referred to as FPGA emulation, allows early access to verification and test preparation for the FPGA before the final result of the design cycle for ICs, referred to as the tape-out phase. Compared to software simulation, FPGA emulation allows for simulated operating frequencies that are several orders of magnitude faster. Hence the designers can run more complex tests and achieve higher testing coverage.
However, FPGA emulation can suffer from a lack of on-chip signal observability and a lengthy recompilation cycle. Observability of the internal signals can be enhanced by instrumentation of the design, but only a limited amount of such instruments can be inserted due to resource constraints. Therefore, only a limited subset of signals can be monitored simultaneously. The monitored subset can be changed by a recompilation, but each instrument-compile-debug iteration can take multiple hours due to this time-consuming recompilation. This severely limits debug productivity and may result in a slow time-to-market.
It is known in the art to insert trace-buffer instrumentation if sufficient spare resources exist in the target FPGA after a version of the circuit is emulated in the FPGA. Such trace-buffer IP can be inserted but require additional area and therefor are limited in number as such additional area is not always available (large designs may use the entire FPGA area). Furthermore, in some FPGA architectures, hardened control logic exists inside RAM blocks to allow circular buffers to be implemented.
For example, specific tools known in the art, e.g. tailored to specific FPGA devices, can embed logic analyzer IP into the user-circuit during compilation. Such logic analyzer IP can for example comprise signal probes, trigger monitors, trace buffers and/or data offload logic. If erroneous behavior is observed, verification tools can be used to add instrumentation to the circuit. Afterwards, the designer may determine the number of signals to be observed and the size of the trace-buffers. The circuit is then recompiled and the error is reproduced. The designer can use the data in the trace-buffer to narrow down the cause of the failure. However, such approach as known in the art may have the disadvantage of requiring signal predetermination and full recompilation. Alternatively, incremental techniques may be known in the art in which internal signals are multiplexed to reserved I/O pin for external analysis. The designer may predetermine the subset of signals to be observed. However, in this approach signal predetermination is also required and run time flexibility via parameterized configuration is not provided.
Furthermore, device-neutral techniques exist in the art that can offer much of the same functionality as described above. Such techniques may for example enable the selection of a small subset of signals during debug-time for observation and triggering, by allowing the designer to pre-instrument a large set of interesting signals in the target FPGA prior to compilation. Run time flexibility may for example be increased by using a multiplexer network. However, this may have the disadvantage of requiring the selection of a set of signals for observation before any bugs are known is required. The solutions such as a multiplexer network also require a lot of extra resources on the FPGA, increasing the used area.
Methods as known in the art may operate primarily on the pre-mapping circuit. Therefore, such methods may instrument the original user circuit with trace-buffers and associated connections before place-and-routing the combined design. Some tools as known in the art may however support a limited amount of reconfiguration. Nevertheless, even though it may be possible to modify the trigger conditions during runtime, changing the signals under observation does require a lengthy FPGA recompilation, even with the more advanced techniques known in the art.
However, methods are known in the art which use a debugging workflow that may bridge the gap between simulation and emulation, bringing good visibility to FPGA-based debugging. Such methodology may use as basis for the observation network a Virtual Overlay Network, implemented in free resources. Spurious recompilations may be avoided by reconfiguring this network during debug-time. However, in typical realistic designs, few available resources are left for the Virtual Overlay Network and the Virtual Overlay Network thus typically may be too small. Thus, insertion of extra instrumentation in the free multiplexers can be impractical in FPGA emulation of a large ASIC design.